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Abstract 



nfs is the de facto standard for file sharing in heterogeneous enterprise networks. Independent 
market research forecasts show strong growth in the nfs multivendor-installed base from 8.5 million 
nodes in 1994 to 12 million nodes in 1997. Although nfs has been shipping since the mid-1980s, its 
continued evolution to support evolving customer requirements has been key to it's continued 
widespread use. 

Specifically, the recent growth in nfs usage is due to the evolution in its capabilities in the areas of 
performance, security, administration, global support, availability, and heterogeneity. These make 
nfs optimal as a foundation for sharing mission-critical information within the enterprise. 

dfs is the file sharing component of the Open Software Foundation's Distributed Computing 
Environment (osf dce). Implementations of dfs started shipping in 1992-1993 for hp-ux, aix, and 
Solaris environments, dfs was designed in the early 1990's to support commercial-level features 
such as global naming support, security, availability, and administration that were not available in 
nfs at that time. However, nfs has evolved since that time to address these requirements. This, 
coupled with nfs's strength as a multivendor standard, makes it the file sharing solution of choice 
for enterprise en vi ron ments. 

This document contains a comparison of the features and benefits provided by the latest client and 
server-side advances in nfs and dfs technologies. Where pertinent, a description of the 
implementation of these features is provided. Unless specifically noted, Auspex is committed to 
supporting all new server-side nfs features discussed in this document (new nfs cl i ent-si de capabi I i ti es 
will typically transparently interoperate with the installed base of Auspex and other nfs servers). 
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1 Introduction 

1.1 nfs Overview 

nfs is a file access protocol that allows transparent access to information on heterogeneous 
enterprise networks. Specifically, nfs is one among a set of services comprising the onc4/nfs 
platform for information-sharing and administration of a client-server environment. onc4/nfs 
Include nis/nis+ naming/information services, rpc/xdr distributed application development 
platform, security services, and client-side caching. onc4/nfs is supported on all key operating 
system environments, ranging from pes to workstations to mainframes, nfs is a client/server 
application built atop onc+ rpc/xdr layer and uses other on c 4/ nfs services. For simplicity reasons, 
"nfs" is used in the rest of this paper to refer to the onc4/nfs collection of services that together 
allow NFS-based high-performance file sharing on today's enterprise distributed networks. 

Specifically, NFShasthefollowingfeaturesand benefits: 

■ nfs clients transparently access remote files as if they were local. Transparent access to remote 
files is provided through an automatic mounting facility. 

■ nfs includes features, such as memory-based caching, to provide equivalent performance for 
remote and local file access 

■ nfs file operations are generic enough to be easily implemented atop all major operating 
systems and file systems, allowing file sharing in a heterogeneous environment. 

■ nfs clients and servers recover quickly and easily from machine and network failures. 

■ nfs security (based on onc4/nfs rpc) ensures files are protected from unauthorized intruders. 

■ Centralized nfs administration (based on onc4/nfs nis or nis+) improves productivity for 
administration tasks such as relocating or renaming files. 

nfs has continued to evolve through a multivendor effort to meet evolving file sharing 
requirements for commercial enterprise networks. Some of the most important new features 
provided by nfs include: 

■ A new revision to the nfs protocol, nfs Version 3, that increases scalability and performance. 
Release 1.9 or later of Auspex's System Software delivers a high-performance, optimized 
implementation of NFS Version 3. 

■ Support of small workgroups to large enterprise networks. 

■ Highly competitive performance enabling fast access to remote information and optional local 
disk caching. 

■ X/Open Federated Naming for intuitive naming of files across the enterprise. 

■ A flexible security architecture allowing support of multiple network security mechanisms. 

■ Auspex's DataGuard and ServerGuard value-added products allowing nfs to be fully tolerant of 
system and network failures. 

1.2 dce dfs Overview 

dfs file sharing service is layered on top of theosF Distributed Computing Environment (dce) and is 
an integral part of dce. dce fundamental services— rpc, naming, security services, time— provide 
value-added capabilities to dfs in the areas of administration, security and availability. Deployment 
of the dce set of services is required for dfs. For simplicity reasons, "dfs" is used in the rest of the 
paper to refer to the full collection of dce services that support DFS-based file sharing. 

dfs is made up of two components: 
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■ Every machine— client or server— sharing files within DFSmust run theDFS Base Service. 

■ dfs file server machines run the Enhanced File Service (efs). efs implements important dfs 
services including backup, replication, server monitoring and server re-start. 

dfs provides the following capabilities over and above basic network filing functions: 

■ Files are cached locally either on a local disk or in memory on client machines. 

■ dfs optionally replicates the files used most often on multiple file servers. 

■ All information supported by dfs servers becomes part of one, unique file system. Global file 
naming allows a file to be accessed with a single file name regardless of the file's physical 
location in the system. 

■ Authentication and access control mechanisms for security. 

This document contains a comparison of the features and benefits provided by the latest client and 
server-side advances in nfs and dfs technologies. Where pertinent, a description of the 
implementation of these features is provided. The specific goal behind this discussion is to help 
system administrators and network architects in making an informed decision about the 
appropriate networking file services to deploy for their environments. 

Unless specifically noted, Auspex is committed to supporting all new server-side nfs features 
discussed in this document (new nfs client-side capabilities will typically transparently intemperate 
with the installed base of Auspex and other nfs servers). Please contact your Auspex representative 
for specific information regarding specific feature avail ability. 
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2 Caching 

Client caching mechanisms are commonly employed in distributed file systems to speed up remote 
file access, increase server scalability and reduce network traffic. Once the client cache is populated 
with file data (such as pages, attributes, and directory information) the majority of file read/write 
operations occur locally on the client, thereby avoiding network traffic and server resource 
utilization. File data is typically cached in units called chunksizes. When an application issues a read 
request for file data, the minimum amount of data that will be fetched from the file server is a 
chunk. For large sequential file reads, a larger chunksize generally yields better performance by 
reducing the overhead associated with the underlying network communications protocols. 

Network file systems may use a read-ahead mechanism that enhance sequential read performance. 
When the mechanism detects sequential ity, the client may issue multiple simultaneous requests for 
chunks. The expectation is that by the time the application issues a read operation on a piece of the 
file, the data may already be in the client cache or in transit from the server. Once data in the cache 
has been modified, these changes must eventually be propagated to the server. This is accomplished 
through the use of delayed-write policies. 

The client cache can be configured in memory or on disk; either choice is useful in lessening the 
amount of server traffic. However, using a memory cache typically yields better performance in 
applications where very large files are used or where cached data are rarely reused. On the other 
hand, a large disk cache may be more appropriate in environments with heavily loaded networks, 
with clients that have small system memories, and/or where file data are heavily reused. A disk 
cache allows the additional benefit of being persistent (that is, information in a disk cache will 
survive a reboot). 

2.1 Caching in nfs 

nfs supports both memory and disk-based client-side caching for improved performance and server 
scalability. All nfs clients use the client's physical memory to cache file pages, file attributes, and 
directory entries. Through page clustering, multiple file pages are combined into chunks of 8 kb. 
Since the size of the cache is limited by physical memory, the degree of performance improvement 
gained by memory-based caching depends on the amount of free memory. 

nfs uses a read-ahead strategy to improve its sequential read performance. The nfs client processes, 
called biods, pre-fetch file data by issuing rpc read requests to the server on behalf of the application 
process that issued the read system call. Each biod can request only a chunksize amount of data at 
onetime. The default (and maximum) chunksize is 8 KBfor both read and write buffers for memory- 
based caching. However, the buffer sizes may be changed by using the rsize and wsize parameters of 
the mount command, nfs implements delayed-write policies for forwarding modifications to the 
client cache to the server, nfs file data changes are forwarded to the server by the biods: 

■ If the memory-based caching system performs page replacement and the write is scheduled. 

■ If the write-behind mechanism schedules the write. 

■ Periodically (every 60 seconds is the default) by the syncd daemon. 

■ Upon a file close or fsync operation. 

2.1.1 Disk-based Caching— CacheFS 

The Cache File System or CacheFS is a new client-side capability that allows local disk caching for 
nfs . Both nfs v2 and v3 clients still cache as much data in physical memory as is available. CacheFS 



Discussed in the Cache Consistency Section (3.0) 
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significantly increases the cache space available to nfs by using the client's disk. Because of the 
greater storage available on disk, data can be cached in 64 kb chunks, and whole directories can be 
cached instead of just directory entries. Expanded cache space means clients can access more data 
quickly and they make fewer requests of the server. 

CacheFS provides dramatic benefits for performance for remote file access. The effect of CacheFS is 
very noticeable as clients attempt to access data from across the local or wide-area network. A cache 
hit to local storage can return data 10 to 100 times faster than across thewAN network. 

2.2 Caching in dfs 

As with nfs, the dfs client cache can be configured in memory or on disk. The dce/dfs equivalent to 
CacheFS is the Cache Manager. The dfs Cache Manager retrieves and caches files in 64 kb chunks on 
a local disk and is managed similarly, dfs also uses a read-ahead mechanism that enhances its 
sequential read performance. In addition, dfs implements delayed-write policies for transferring 
modifications in the client cache to the server, dfs file data modifications can be propagated to the 
server in the following ways: 

■ On a periodic basis (every 30 seconds) by one of the dfs client processes. 

■ If the server revokes the client's write token. 

■ If the dfs client cache becomes full. 

■ Upon a file close or fsync operation. 

2.3 Comparison Summary 

nfs and dfs both provide equivalent functionality for client-side caching. Both file services support 
memory and disk-based caching and support a maximum of 64 kb cache chunksize. Both allow 
read-ahead and delayed-write mechanisms with flexible setting of policies. 



CacheFS is a client-side nfs feature support by on platforms including systems from SGI, Sun, hp, and pes 
Tokens are discussed in the Cache Consistency section. 
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3 Cache Consistency 

As discussed in the previous section, client-side caching is key to allowing improved user response 
time and server capacity for distributed file systems. Cache consistency refers to mechanisms used 
to determine the validity of cached data and the propagation of cache modifications to the server. 
Cache consistency is important in ensuring that data is safely written to the server while at the 
same time minimizing the amount of time an application waits for its data to be written to stable 
storage. 

Cache consistency mechanisms cannot be thought of as substitutes for strong transactional 
consistency to protect file data in the face of concurrent writes by multiple clients. Applications that 
concurrently write to files typically use file locking to protect transactional consistency for remote 
file access. This option is provided for network file system clients and servers through standard Unix 
advisory locking and similar locking mechanisms on other operating environments. In addition, 
applications, such as network-based ecad, mcad, and software development packages that require 
strong file or directory consistency typically incorporate their own locking and synchronization 
techniques for remote file access. 

3.1 Cache Consistency in nfs 

The basis of the nfs cache consistency model is the time-limiting of the validity of cached data by 
clients. This time varies between 3 and 60 seconds, depending on the frequency of update. A file 
that is updated frequently will have a short cache time-out (nearer 3 seconds), while a file that is 
updated infrequently will have a longer cache time-out (nearer 60 seconds). These limits are 
configurable on a per-mount basis, so that cache consistency can be improved by adjusting the 
lower limit to values smaller than 3 seconds— or even zero. This exacts a trade-off in cache 
effectiveness, short time-outs increase the rate of consistency checks with the server. Similar cache 
consistency is maintained with directory entries, though with limits between 30 and 60 seconds. 

nfs implementations guarantee doseto-open consistency. All file modifications are written to the 
server when a file is closed. When an application opens a file, it invalidates cached data if it detects 
that the file has changed on the server. This close-to-open consistency guarantees that after a file is 
closed its contents will be visible instantly to applications elsewhere on the network that open the 
file. 

The nfs close-to-open cache consistency mechanism is a light weight, efficient means for ensuring 
validity of cached data. Frequently, mention is made of a drawback in this mechanism: that it does 
not guarantee data validity in the face of write conflicts (where two or more clients attempt to open 
a file for write access concurrently). However, it is a misconception that cache consistency 
mechanisms in network file systems such as nfs are designed to solve the problem of concurrent file 
access. Specifically, 

■ Write conflicts are a very infrequent occurrence in typical network file access patterns 
[Welch91]. 

■ Use of nfs file locking technology, called nfs Lock Manager, is required where fine grained 
control over concurrent file access is desired. 

3.1.1 Cache Consistency and Write Throughput 

The nfs v2 client stores the data in the local cache as the first step of a write request. After the data is 
written to the cache, the application that issued the request continues with its operation. In 
parallel, the client takes the written data and submits corresponding write requests to the server. The 
nfs server then writes the data serially to stable storage and responds to the client. Because each 
individual nfs write request from the client requires that data must be written to stable storage on 
the server before it completes, this mechanism is known as synchronous writes. 
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The nfs v3 protocol [Pawlowski94] dramatically increases write throughput by eliminating the 
synchronous write requirement while retaining the benefits of close-to-open semantics. Specifically, 
the nfs v 3 client retains a copy of written data which has not been the subject of a commit call (and 
will retransmit this in the event of a server failure). From time to time, and always at file close time, 
the client sends a commit request for outstanding data. The server must ensure that all such data is 
on stable storage before responding to the commit request. However, since the server starts 
asynchronous writes of data as soon as it is received, there will normally be very little data which is 
not already on disk at commit time. Thus, the overall throughput approximates that of fully 
asynchronous write behavior. This feature, referred to as safe asynchronous writes, vastly reduces the 
number of write requests to the server, and thus significantly improves write throughput. 

3.2 dfs Cache Consistency 

dce/dfs maintains cache consistency with a server-based token scheme. When accessing a file, a 
client is required to hold a token that reflects the type of file access permitted to the client. To read a 
file a read token is required from the server. To write to a file the client must request a write token 
from the server. If a client requests a write token for a file that has several clients reading from it, 
the server will send a message to the reading clients to invalidate cached data from this file. This is 
to ensure that they see the most recent data in the file. In the dfs to ken -based scheme, close-to- 
open semantics need not be enforced because the outstanding data can be written to the server after 
the application closes the file. The server will notify the client to yield its token whenever another 
process wishes to access this file. 

dfs is similar to nfs v3 in its support of safe asynchronous writes. In the case of dfs, file data may 
still be in the server's memory and not yet in stable storage when an application's file close call 
returns, dfs does, however, commit data to non-volatile storage prior to returning from an fsync call. 

dfs cache consistency model may have problems when a failure occurs during the time a client 
process possesses a token. For example, if a client holding a file's token crashes or if a network 
partition occurs, the server is required to handle complex exception cases (for example, if a new 
client wishes to access the same file). Problems can also be caused when the first client comes back 
and has to resolve changes made to the file during its absence. A labor intensive approach isto have 
the system administrator decide how to handle tokens on a case by case basis. 

3.3 Comparison Summary 

In summary, it is easy to see that dfs token passing can be difficult to administer and complicated 
to implement. The asynchronous write feature of nfs v3 provides the same performance and 
reliability benefits without the administrative overhead. 

Another key point to note regarding the dfs token-passing cache consistency model is that it alone 
cannot solve the problem of concurrent file access by multiple client processes. As with nfs, dfs 
requires a locking mechanism to enable synchronized write access by multiple clients to a single 
file. 
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4 Administration 

Distributed computing infrastructure components must enable simplified administration of today's 
dynamic enterprise network environments. Thus, the ability to manage change must be a key 
requirement for selecting distributed file systems. Network file services should enable streamlined 
implementation of tasks such as adding, deleting, relocating, and changing file system 
configuration information. Finally, it should be possible to administer the file system centrally, 
thereby minimizing time and effort required to keep the distributed file services up and running. 

4.1 nfs Auto mounter 

nfs includes a capability called the automounter that provides two key administrative benefits: it 
gives users, workgroups and applications location-independent access to server file systems and it 
allows a means for accomplishing administrative operations, such as adding or relocating file 
systems, in a centralized fashion. 

Automounter allows associations between client pathnames and server file systems. The 
automounter converts these associations or mappings into actual file system mounts and adds them 
to the client's file tree. In this way, the mappings define the nfs namespaceor the client file names 
that are used to access server file systems. 

The nfs namespace can be modified to suit the specific needs of different environments. 
Administrators can establish their own naming policies for simplified access to remote file systems. 
For example, it is common to set up all users home directories under /home/username or all shared 
manufacturing files under /mfg/shared. 

The nfs namespace is also a global or shared namespace. This means that the client pathnames are 
valid throughout the network. Users can move to different locations within the network and are 
still able to access files and directories using the same pathnames they used when they were on their 
home system. 

The global nfs namespace is configured by editing automounter maps. The fact that maps are stored 
in the name service (eg. nis or nis+) enables the namespace to be administered centrally— no "per 
client" administration is necessary. For instance, the /home directory is associated with a map, 
autohome, that describes the location of every user's home directory, for example, 

John echo:/export/home/john 

jim monterey:/export/home/jim 

The automounter makes paths like /home/john work across the organization even if the specific 
directory is moved to a different server. This allows increased mobility allowing, for example, the 
user John to log into any workstation and find that the current directory is his home directory. This 
path is valid even on the server machine echo since the actual location of the home directory is 
private to the automounter map entry. 

The automounter also enables efficient read-only replica location. Any map entry may describe 
several locations for a read-only file system. When mounting the file system, the automounter will 
choose the server that has the nearest network proximity thereby improving response time and 
reducing network traffic. 



Automounter isa nfs client-side capability and is supported in nfs implementations for a range of operating 
environments including hp-ux, aix, Sunos/Solaris, dos, Windows 3.11 and WindowsNT. 
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4.2 dfs Namespace 

The dfs file namespace of an organization consists of asingle directory tree spread over any number 
of dfs file servers. DFSdoes not require you to know which machine holds your files and directories. 
To access a dfs file, you need to know the dfs path name of the file. 

A dfs pathname has three components: the cell name, the dfs junction, and the location of the dfs 
file in the dfs namespace. For example, suppose a user named Judy is from the cell or organization 
abc.com. A directory to which Judy can connect is her home directory: //.../abc.com/fs/usr/judy. In the 
pathname, //.../abc.com indicates the cell name, /fs indicates the file namespace designation in the 
abc.com cell, and /usr/judy indicates the user's home directory. If the directory /other resides in Judy's 
home directory, she can access the directory with the path name //.../abc.com/fs/usr/judy/other. 

dfs does not require per-client administration as file naming and location information are stored in 
the dce Cell Directory Service (cds). dfs also allows users and applications to access files in a 
location-independent fashion using thefile name-to-location mapping information stored in cds. 

4.3 File Naming Using X/Open Federated Naming (xfn) 

X/Open Federated Naming (xfn) [xfn 95] is a powerful facility that allows network applications to 
consistently and easily access the diverse range of network entities such as files, printers, and 
spreadsheets, across the global network, xfn is based on X/Open Preliminary Specification for Federated 
Naming, (July 1994). The specification has been endorsed by major vendors such as ibm, Hewlett- 
Packard, SunSoft, dec, Siemens-Nixdorf, and Open Software Foundation (osf) as the standard means 
for accessing network resources such as files, printers, and spreadsheets, across enterprise networks 
xfn support for nfs is shipped by Sun as a component of Solaris 2.5. SunSoft is also licensing xfn 
portable source for nfs to onc4/nfs vendors, osf plansto ship xfn support for dfs to its technology 
licensees as a component of dce 1.2 in early '97. 

XFN-based file naming uses xfn naming policies to provide users with a consistent, intuitive means of 
accessing file systems across the enterprise. Files may be named relative to users, organizations, 
hosts, and sites, xfn -based file naming gives users a consistent view of file systems across the 
enterprise or global network. Existing applications can access file systems supported by xfn, such as 
nfs or dfs, just as they would any other file system and are not required to use the xfn API. Further, 
no changes on installed base of file servers is required in order for clients to use XFN-enabled file 
naming policies to access such servers. 

xfn policies enable network entities such as users, hosts, organizations, services, and files to be 
named in a logical and hierarchical manner. For instance, a user may be named relative to the 
organization he is in, and a directory may then be named relative to that user. As an example, the 
project directory of the user Steve in the software division of an enterprise might be accessed by: 

% cd /xfn/org/software.eng/user/steve/fs/project 

The notations "org", "user", "fs" in this example are references to the organization or cell, user, and 
file system namespaces respectively. The organization name " software. en g" is a specific cell or 
domain name. 

Files from other organizations within the namespace hierarchy may be accessed in a similar fashion. 
In addition, users in the same organization as Steve have the option of using a shorthand notation 
that looks like the following: % cd /xfn/user/steve/fs/project 

xfn also allows files to be associated with organizations, not just users or hosts. These files can be 
shared across an organization. 

4.4 Comparison Summary 

In summary, the naming/location models employed by the two filing services allow nfs to provide 
key val ue-added overDFSin thefilesystem administration area. Specifically, 
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Both file services allow centralized file system administration and location-independent file 
server access through employing a global namespace. 

nfs global namespace is configurable allowing administrators to setup naming policies to suit 
the needs of their organization, dfs global namespace is fixed. 

xfn is the next-generation file naming/location capability for both nfs and dfs However, xfn 
support in technology and product versions of nfs has been available since 1995 while xfn 
support for dfs will be available in 1998 at the earliest. 
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5 Availability 

Continuous accessibility of files to users and applications on the network has to be a key 
requirement for distributed file systems. This is especially true in mission-critical environments 
where any interruption of service can quickly translate into lost business. There are a number of 
techniques through which distributed file systems may provide improved availability to users and 
clients. These include support of replicated or redundant servers for continuos access to file server 
data in the face of server or network failures and highly available data service in the face of server 
hardware or software component failures. 

Replication functionality in network file systems is a client- and server-side capability. It can be 
supported for either read-only or read-write data. Read-only replication refers to support for 
redundant servers containing program binaries or data that does not change very frequently. Read- 
write replication refers to replicated servers supporting data that may be read as well as modified by 
authorized clients. In addition to improving data availability, replicated servers provide a number of 
key administrative benefits. These include distributing client load over a number of servers and 
keeping traffic off of network backbones by placing servers near clients. Network file systems may 
allow clients to failover to a read-only replicated file server at either mount time or whenever a 
network or server failure occurs. 

Highly available data service is a server-side capability that provides a much higher level of fault 
tolerance compared to replicated read-only servers. The goal behind this functionality is to provide 
continuous read-write access to file server data in the face of failure of any of the software or hardware 
components of the server. It typically requires duplication of both hardware and software so that 
when one component fails, another can takeover. 

5.1 High Availability in nfs 

Automounter capability in nfs supports replication of read-only file systems. An automounter map 
entry for a read-only file system may describe several locations for alternative replica servers. At 
mount time the automounter mounts the file system on the server that has the nearest proximity to 
the client. This reduces network routing delays, helps keep nfs traffic off the corporate backbone, 
and improves server scalability. 

In addition, there are a number of products from third parties such as Auspex that provide server- 
side capabilities for highly available nfs data services. Notable among these are DataGuard and 
ServerGuard high availability software. DataGuard is a software solution that eliminates nfs service 
downtime that may be caused byuNix and application instability as well asuNix reboots. It allows 
full read/write access to nfs data to continue uninterrupted in face of such events. ServerGuard is a 
software- based failover solution designed to provide continuous read/write access to nfs data even 
in the event of a complete system failure. ServerGuard automatically and transparently mirrors file 
systems on two separate servers on the network. Should either server experience a hardware or 
software failure, the other server will take over in typically less than 5 seconds allowing for very 
high availability. 

5.2 High Availability in dfs 

dfs optionally supports replicated servers. Unlike nfs replication, replication in dfs is supported for 
both read-only and read- write data. In addition, dfs allows clients to dynamically failover to another 
replicated server in case of server or network failures whereas the automounter-based replication 
capability in nfs allows client failover only at mount time. 
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5.3 Comparison Summary 

Base-level dfs provides more availability functionality than standard nfs. This includes DFSsupport 
for read-write replication and dynamic client failover. Unlike dfs, however, nfs supports value- 
added solutions from third parties, such as Auspex'sServerGuard and DataGuard software, allowing 
very high availability for nfs data services in the face of network and server hard ware/ software 
failures. Such products combined with nfs's track record of deployment in production 
environments make it a superior choice as the infrastructure for mission-critical data services. 
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6 Global Support 

Access to information across global networks is a requirement for corporations wishing to compete 
successfully in the global economy. Global expansion has given rise to workgroups spread across the 
multiple locations around the world. This has created an environment where file systems must span 
geographies. In addition, the exponential growth in Internet use is making Internet- based access a 
key distributed file system requirement. Asa result, the definition of a network server has expanded 
to cover fi le servers over lans and wans. 

6.1 Global Support in nfs 

nfs supports global workgroups by giving users transparent, fast access to server file systems 
connected to client systems on lans and wans. The following capabilities enable efficient global 
access: 

■ nfs servers and clients now also support the tcp transport protocol that provides improved 
performance and reliability for wan support. Unlike udp, tcp is a reliable protocol that is 
designed to provide guaranteed data delivery. Further, all nfs client traffic can be multiplexed 
over one tcp connection to the server. This keeps overhead to a minimum and allows servers 
to scale to serve large numbers of clients. 

■ Automounter keeps files continuously accessible through client-side mount-time failover to 
read-only file systems on servers worldwide. 

■ Client side caching gives clients fast access to file data transferred from the remote server and 
stored locally. 

■ Auspex's ServerGuard product can allow dynamic failover to read/write file systems on nfs 
servers for a wide range of hardware and software failures. 

6.1.1 WebNFS 

WebNFS is an nfs extension designed to make nfs compatible with firewalls and allows Web 
browsers and other Web clients to directly access nfs file servers anywhere on the Intranet or 
Internet. WebNFS complements http by providing a high performance file access protocol suitable 
for down-loading static data such as program binaries or images across Intranet/Internet. WebNFS 
can deliver files over the Internet or corporate intranets up to 10 times faster than http. Web sites 
that use both http and WebNFS can support up to three times as many user requests as a site that 
uses only http. WebNFS takes advantage of nfs support for tcp/IP, which provides congestion control 
and error recovery, for reliability and performance over the Internet. In addition, it implements 
mechan isms for si mpl ified fi le access across I nternet-based I i n ks. 

A number of client and server vendors, including Auspex, Netscape, Oracle, Sun, JavaSoft, Spyglass, 
and Sequent, have announced plans for support of WebNFS. In addition, a specification of WebNFS 
has been submitted as a draft rfc to ietf. 

6.2 Global Support in dfs 

dfs provides tcp support and client-side caching for high-performance and reliable WAN-based file 
sharing. It also provides dynamic client-side failover to replicated WAN-based file servers supporting 
read-only and read-write filesharing. 

6.3 Comparison Summary 

Both nfs and dfs contain important functionality for supporting file sharing across global 
environments, dfs and nfs are equivalent in tcp support and client-side caching for high- 
performance and reliable file sharing across WAN-based networks, dfs provides additional availability 
benefits for global environments in allowing support for dynamic client-side failover to replicated 
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servers for read-write file sharing. However, nfs provides a very high degree of availability for wan - 
based environments through deployment of Auspex's ServerGuard product. Finally, nfs is alone in 
supporting a high-performance file access protocol for Internet/Intranet using WebNFS. 
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7 Security 

Network file systems are inherently vulnerable to unauthorized access due to their distributed 
nature. There are two specific threats to the security of a distributed file system: compromise of file 
server security through impersonating a client's identity and sending of forged requests to a file 
server to access or destroy fi le data. 

7.1 nfs Security 

nfs supports two types of security services: authentication and authorization services. The purpose of 
the authentication service is to validate user's identity before allowing them to use resources, nfs 
can be optionally configured to use an authenticated protocol, called SecureRPC, to provider 
authenticated file access. Multiple types of authentication services are supported including one 
based on the Diffie-Hellman key exchange protocol, another using Kerberos, and the third using a 
simpler "unix" style authentication, nfs is able to utilize multiple authentication "flavors" by virtue 
of the flexibility of the underlying rpc service. The use of authentication causes a performance 
overhead and its optional use allows sites to decide if their security requirements justify such a 
scheme. 

Diffie-Hellman and Kerberos authentication schemes use encryption to protect authentication 
information. Information is protected using an encryption algorithm with a special value or "key." 
Knowledge of the decryption key is required to convert the data back into readable form. 

The purpose of an authorization service is to ensure that users have appropriate permissions to 
perform specific operations, such as reading or modifying files, once they have been authenticated. 
nfs supports unix style authorization (or "permission checking"), unix style permissions involve 
using the file permission bits functionality that is a standard part of unix. Permission bits are set to 
indicate whether read, write and/or execute permission is allowed for the owner of the file, the 
members of certai n groups or for the world. 

7.2 dfs Security 

dfs supports only Kerberos authentication. All communication between dfs clients and servers takes 
place using the authenticated rpc mechanism. In addition, every user is required to have a private 
key stored on a Kerberos ticket granting server. 

dce/dfs provides support for Access Control Lists (acls) which expand the amount of 
file permission information beyond standard unix permission checking. Every file has an associated 
acl. Clients identify themselves to the acl manager by providing a list of identification 
values including their uid and gids. The dfs server is responsible for responding to client 
requests by comparing the client permission values to the file's acl and either granting or denying 
access. 

7.3 Comparison Summary 

The nfs authentication model allows a number of degrees of flexibility not available in the dfs 
authentication model. These are: 

■ nfs allows sites to choose if they want to deploy authentication services or not in view of their 
security requirements, dfs, on the other hand, requires the use of Kerberos-based 
authentication. This is important as the use of encryption-based authentication mechanisms 
like Kerberos have additional network performance overhead. 
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■ nfs allows use of multiple "flavors" of authentication such as Kerberos and Diffie-Hellman 
whereas the dfs authentication is limited to support of Kerberos. The rpc mechanism 
underlying nfs has the flexibility to support newer encryption models such as the rsa 
encryption which is more prevalent on the Internet. 

dfs is superior to nfs in the support of acls that provide a finer level of file access control than is 
allowed by unix permissions. However, use of acls requires additional overhead in setup and on- 
going administration of acl information. 
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8 Performance 

High performance is an important criterion for measuring the effectiveness of a distributed file 
sharing solution. Distributed file sharing performance is intimately tied to the productivity gains 
made possible through information sharing across enterprise networks. 

8.1 nfs Performance 

nfs performance has increased an order of magnitude in the last five years, from hundreds to 
thousands of operations per second. The industry standard laddis benchmark developed by SPEC 
motivates nfs vendors to aggressively tune their latest systems and publish updated benchmark 
results. In addition, nfsv3 protocol and client-side disk caching (discussed in the Caching section) 
allow enhanced performance. The features of nfs v3 contributing to improved nfs performance are 
discussed below. 

8.1.1 nfsv3 Performance Improvements 

nfs v3 includes a range of performance improvements. The first key improvement is the support of 
safe asynchronous writes (discussed in the section on Caching) which shows about 100% 
improvement in write throughput in theAuspex NFS implementation between similarly configured 
clients and servers upgrading from nfs v2 to nfsv3. 

nfs v3 also implements fewer on-the-wire operations between clients and servers for improved 
performance, nfs v2 clients check to make sure that their cached data does not become invalid by 
periodically acquiring the file's attributes, which includes the time the file was last modified. Clients 
obtain file attributes by periodically querying the server with a getattr request, nfs v3 keeps these 
attributes requests to a minimum by returning attribute information for all operations, thus 
increasing scalability and performance. 

nfs v2 has an 8 kb maximum buffer size limitation which restricts the amount of data that can be 
sent over the network at any onetime. In nfs v3, this restriction has been relaxed, enabling nfs to 
construct and send large chunks of data. This allows nfs to more efficiently utilize high bandwidth 
network technologies such as fddi and 100BaseT and has contributed substantially to nfs 
performance gains. 

8.2 dfs Performance 

Unlike nfs, there is no industry standard benchmark for dfs nor is generally available, vendor- 
independent information available on performance of different dfs implementations. Thus, a 
comparison of nfs and dfs performance is very difficult. 

8.3 Comparison Summary 

nfs demonstrates a track record of providing requisite performance for mission-critical applications 
across large-scale networks, nfs v3 implements features designed to enhance performance further. 
There is very limited publicly available information on dfs performance. 
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9 Multi platform Support 

It is typical for corporations to have a mixture of dissimilar system that do not allow information to 
be easily shared throughout the corporation. The availability of open, multiplatform solutions is 
very important to those integrating heterogeneous systems into enterprise networks. 

9.1 Multiplatform Support for nfs 

The multivendor nfs installed base tripled during 1991-1994 [Dataquest95] and is expected to grow 
from 8.5 million nodes in 1994 to 12 million nodes in 1997. Growth in nfs deployment is forecast 
to be strong in both unix and pc segments and it is expected to remain the dominant distributed 
file service for heterogeneous environments. 

nfs is considered an open standard. It is described in several Internet rfcs [ietf1,ietf2] and is also 
part of X/Open'sCAE (Common Application Environment) specification, nfs code is licensable. nfs 
implementations either developed from rfc specifications or portable source are available today on 
every major operating system and hardware platform, nfs is a core component of all unix variants. 
In addition, nfs software products exist for MS-DOS/Windows/WFW/Windows nt, vms, Macos, and 

MVS. 

9.1.1 Connectathon 

The goal of the annual Connectathon event is to provide a forum for different vendors to test 
interoperability of their nfs client and server products. Almost all major hardware and operating 
system vendors are represented at Connectathon. Connectathon serves another important purpose: 
to provideaforum for nfs vendors to plan improvements to nfs. Enhancements such asNFSv3 have 
been the result of such work. 

9.2 M ultiplatform Support for dfs 

dce fundamental services and dfs are in relatively early stages of deployment. Little data is publicly 
available regarding existing or projected installed base for dce or dfs. 

Implementations of dce fundamental services for primarily unix and pc operating environments 
have been shipping since 1992-1993. These include implementations for hp-ux, aix, Sunos/Solaris, 
and Dos/Windows environments, dfs implementations (available only as add-on products) for unix 
environments have been shipping since 1995. PC implementations for dfs (limited to supporting 
Windows nt) have been shipping only since 1996. 

9.3 Comparison Summary 

nfs has much stronger multivendor support, a much larger installed base and de facto standard 
status compared to dfs This makes it a much superior offering as an enterprise-level data services 
infrastructure. 
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10 Conclusion 

This paper has a key thrust: to compare nfs and dfs distributed file services on how each meets key 
requirements for mission-critical information sharing in enterprise networks. These include caching, 
administration, availability, administration, global support, security, and performance. The 
comparison indicates the following conclusions: 

■ nfs and dfs both provide equivalent functionality for client-side caching, dfs token passing 
can be difficult to administer and complicated to implement. 

■ Both file services allow centralized file system administration and location-independent file 
server access, nfs global namespace is configurable allowing administrators to setup naming 
policies to suit the needs of their organization while dfs global namespace isfixed. 

■ xfn is the next-generation file naming/location capability for both nfs and dfs However, xfn 
support for nfs has been available since 1995 while xfn support for dfs will be available in 
1997 at the earliest. 

■ Base-level dfs provides more availability functionality than standard nfs such as support for 
read-write replication and dynamic client failover. Unlike dfs, however, nfs supports value- 
added solutions from third parties, such as Auspex's ServerGuard and DataGuard software, 
allowing very high availability for nfs data services. 

■ The nfs authentication model allows a number of degrees of flexibility not available in the dfs 
authentication model, dfs is superior to nfs in the support of acls. However, use of acls 
requires additional overhead in setup and on-going administration. 

■ nfs demonstrates a track record of providing requisite performance for mission-critical 
applications across large-scale networks, nfs v3 implements features designed to enhance 
performance further. There is very limited publicly available information on dfs performance. 

■ nfs has much stronger multivendor support, a much larger installed base and defacto standard 
status compared to dfs 

The overall conclusion of the paper is that nfs is a significantly superior solution for information 
sharing in multivendor enterprise network environments. Auspex is strongly committed to 
supporting the latest advances in nfs technology and in allowing NetServer customers to take 
advantage of such technology in a timely fashion. In addition, Auspex continues to monitor dfs 
evolution and will support it if market conditions warrant. 
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